Виктор прислал мне презентацию от того самого Ивана, который на одной из юзер-групп VMware рассматривал особенности дизайна и проектирования виртуальной инфраструктуры VMware vSphere. Часть, касающаяся виртуализации различных типов нагрузок в гостевых ОС виртуальных машин показалась мне очень интересной, поэтому я решил перевести ее и дополнить своими комментариями и ссылками. Итак, что следует учитывать при переносе и развертывании различных приложений в виртуальных машинах на платформе vSphere.

Наш с вами коллега, Анатолий Вильчинский, проводит в ближайшие дни 2 интересных вебинара по продукту номер 1 для создания отказоустойчивых хранилищ под виртуализацию - StarWind iSCSI SAN.

Первый вебинар, который пройдет 11 июля в 19-00 по Москве, посвящен версии продукта StarWind 5.8 (есть также бета 5.9) для серверов VMware vSphere и называется "Storage Evolution & StarWind v5.8 Solutions ".

Зарегистрироваться.

На следующий день, 12 июля в 22-00 по Москве, вы можете послушать новости о продукте StarWind Native SAN for Hyper-V, который позволяет построить недорогую инфраструктуру отказоустойчивых хранилищ на базе всего лишь двух серверов виртуализации, которые будут одновременно и хост-серверами и хранилищами, что позволит вдвое сократить затраты на оборудование. Итак, регистрируемся на вебинар "StarWind Solutions for Hyper-V Environments".

Зарегистрироваться.

Приходите, будет интересно. Тем более, что Анатолий ответит на все ваши вопросы на русском языке.

Если у вас в виртуальной инфраструктуре большой набор хранилищ, хостов VMware ESXi и виртуальных машин, то легко не заметить один интересный момент - бесполезные vswp-файлы для виртуальных машин, размещенные в папке с ВМ. Выглядят они как <что-то там>.vswp.<номер чего-то там>:

Как видно из картинки, файлы эти не маленькие - размер vswp равен объему памяти, сконфигурированной для виртуальной машины (vRAM) без Reservation для RAM (если есть reservation, то размер vswp = vRAM - Reservation). Так вот эти файлы с номерами - это ненужный мусор. Образуются они тогда, когда хост ESXi падает в PSOD с запущенными виртуальными машинами.

Эти файлы, понятно дело, надо удалить. Для этого удобнее всего использовать PowerCLI:

dir vmstores:\ -Recurse -Include *.vswp.* | Select Name,Folderpath

Пример вывода мусорных файлов vswp с путями:

Ну а дальше сами знаете, что с ними делать.

На сайте проекта VMware Labs появилась новая интересная утилита Guest Reclaim, позволяющая уменьшить размер "тонкого" (thin provisioned) диска виртуальной машины из гостевой ОС Windows, истребовав нулевые блоки. Напомним, что когда тонкий диск виртуальной машины растет по мере наполнения данными, а потом вы эти данные в самой гостевой системе удаляете, его размер не уменьшается.

Один из способов уменьшить диск машины в VMware vSphere - это использовать утилиту sdelete для очистки блоко и перемещение виртуальной машины на другое хранилище средствами Storage vMotion. Однако, если вы прочтете нашу статью про datamover'ы при Storage vMotion и вспомните, что VMware vSphere 5 использует унифицированные блоки размером 1 МБ для всех хранилищ, то поймете, что этот способ больше не работает, поскольку в датамувере fs3dm не реализована процедура вычищения блоков целевого виртуального диска.

Есть конечно способ отключить fs3dm и, все-таки, уменьшить виртуальный диск машины на ESXi, однако это не очень удобная процедура. Поэтому сотрудники VMware и сделали удобную консольную утилитку Guest Reclaim, которая позволяет уменьшить диск с файловой системой NTFS.

Поддерживаются следующие гостевые ОС:

• Windows XP
• Windows Vista
• Windows 7
• Windows Server 2003
• Windows Server 2008

Запускать утилиту нужно из гостевой ОС, в которой есть диски, являющиеся тонкими. Чтобы просмотреть список тонких дисков используйте команду:

GuestReclaim.exe -list

Если ничего не найдено - значит первые 16 дисков не являются тонкими или у вас ESXi 5.0 и ниже (читайте дальше). VMware предлагает приступать к уменьшению диска, когда у вас разница между размером VMDK и файлами гостевой ОС хотя бы 1 ГБ, при этом для работы самой утилиты может потребоваться дополнительно 16-100 МБ свободного места. Также перед началом использования утилиты рекомендуется запустить дефрагментацию диска, на которую тоже может потребоваться свободное место (будет расти сам VMDK-файл).

Команда, чтобы уменьшить тонкий VMDK-диск за счет удаления нулевых блоков, выполняемая из гостевой ОС:

guestReclaim.exe --volumefreespace D:\

Еще одно дополнение - утилиту можно использовать и для RDM-дисков.

А теперь главное - утилита работает только в случае, если hypervisor emulation layer представляет гостевой ОС диски как тонкие. В VMware ESXi 5.0, где Virtual Hardware восьмой версии, такой возможности нет, а вот в ESXi 5.1, где уже девятая версия виртуального железа - такая возможность уже есть. Соответственно, использовать утилиту вы можете только, начиная с VMware vSphere 5.1 (бета сейчас уже у всех есть), а пока можно использовать ее только для RDM-дисков.

Из ограничений утилиты Guest Reclaim:

• Не работает со связанными клонами (Linked Clones)
• Не работает с дисками, имеющими снапшоты
• Не работает под Linux

Из дополнительных возможностей:

• Поддержка томов Simple FAT/NTFS
• Поддержка flat partitions и flat disks для истребования пространства
• Работа в виртуальных и физических машинах

FAQ по работе с утилитой доступен по этой ссылке. Скачать утилиту можно тут.

На прошедшей конференции Google I/O 2012 было анонсировано много чего интересного: Android 4.1 Jelly Bean, планшет Nexus 7, медиаплеер Nexus Q, приняты предварительные заказы на Project Glass для разработчиков, анонсировано расширение магазина Google Play и прочее.

Но нас с вами интересует, конечно же, не это. Главная для нас новость - это анонс нового публичного IaaS-облака от интернет-гиганта, которое называется Google Compute Engine. На конференции было продемонстрировано приложение по обсчету генома, запущенное в кластере из 1250 виртуальных машин (у каждой 8 ядер) на этой платформе, что, возможно, намекает на направленность Google на сегмент "Big Data", а также научные и исследовательские задачи крупных компаний и университетов.

Google Compute Engine - это новый сервис аренды вычислительных сред в публичном облаке (IaaS) на базе ОС Linux, предоставляющий услуги на базе платы за почасовое потребление ресурсов (вычислительные мощности и хранилища). Поддержки Windows в данных вычислительных средах пока не заявлено. Напомним, что у Google уже есть PaaS-платформа App Engine и сервис облачного хранения Cloud Storage. Сам сервис Compute Engine (CE) доступен для пробного использования только по приглашениям (Limited Preview).

Таким образом, мы получаем трех потенциальных лидеров рынка IaaS-сервисов из публичного облака: старейший Amazon AWS, анонсированный в начале июня Microsoft Windows Azure и Google Compute Engine. Особняком стоит компания VMware, предоставляющая решения VMware vCloud, на базе которых любой сервис-провайдер может построить публичное облако. При этом VMware не скрывает своей направленности исключительно на крупный корпоративный сектор (сейчас существует около 125 сертифицированных публичных облаков vCloud от партеров VMware по программе VSPP в 26 странах, которые предлагают аренду виртуальных машин). Отметим также и решение Citrix Xen Cloud Platform от компании Citrix и сообщества Xen.

Основные особенности Google Compute Engine:

• Вычислительные среды. Доступны в конфигурации 1,2,4 или 8 ядер на Linux-платформе с 3,75 ГБ оперативной памяти на одно ядро.
• Хранилища. Можно хранить данные виртуальных машин в виде непостоянных (Ephemeral), а также постоянных (Persistent) дисков на стороне Google или в сервисе Google Cloud Storage. Для постоянных дисков можно делать снапшоты в целях резервного копирования, а также предоставлять доступ к одному диску со стороны нескольких ВМ. Все данные дисков шифруются.
• Сетевое взаимодействие. Возможность использовать высокопроизводительное сетевое оборудование датацетров Google и самостоятельно конфигурировать сетевые экраны, также использовать внешний IP-адрес. Плюс готовые решения от сторонних вендоров, которые выступают партнерами Google.
• Управление. Виртуальными машинами можно будет управлять через веб-консоль или CLI, также есть API, предоставляющий множество возможностей разработчикам и сторонним производителям.

Google Compute Engine будет интегрирован с партнерскими решениями RightScale, Puppet Labs,OpsCode, Numerate, Cliqr, MapR и другими.

Безусловно, Google вступает на рынок IaaS-решений довольно поздно. Но это только одна сторона медали - на самом деле, более 90% компаний вообще еще не пользовались облачными ресурсами уровня IaaS, поэтому потенциал рынка огромный. Также отметим возможную "нишевость" сервиса от Google, если он будет направлен на высокопроизводительные вычисления по цене существенно меньшей, чем у конкурентов.

Кстати, о цене. Заявленные цены выглядят так:

Значение GCEU (Google Compute Engine Units), которое вы видите в правой колонке - это аналог Amazon EC2 Compute Unit (как написано тут), т.е. где-то эквивалент 1.0-1.2 ГГц на процессорах 2007 Opteron or 2007 Xeon.

Также на сайте thenextweb.com проведено сравнение анонсированных цен на Google Compute Engine и уже объявленных Microsoft на Windows Azure. По расчетам получается, что при где-то одинаковой цене мощностей Google Compute Engine и Windows Azure, сервис от Google дает на 50% больше оперативной памяти для ВМ.

В последнее время стало модным предоставлять виртуальные машины в аренду по модели IaaS. Этим занимается VMware со своей платформой vCloud в корпоративных инфраструктурах, а также Amazon, Microsoft и Google - в публичных облаках. Программы для облачных провайдеров есть также и поставщиков сопутствующих продуктов в сфере виртуализации, например, у Veeam и Кода Безопасности.

Теперь и компания StarWind позволяет провайдерам услуг использовать в датацентрах свои продукты StarWind iSCSI SAN и StarWind Native SAN for Hyper-V (статьи о продуктах тут и тут).

Напомним, что продукты StarWind позволяют создавать отказоустойчивые конфигурации хранилищ на базе iSCSI для виртуальных машин VMware vSphere, Microsoft Hyper-V и Citrix XenServer. При этом не требуется инвестиций в дорогостоящие хранилища Fibre Channel и сетевую инфраструктуру SAN, что делает продукты StarWind наиболее эффективными с точки зрения стоимости владения и единовременных капитальных затрат на создание инфраструктуры датацентра.

Кроме того, StarWind это:

• Динамическое масштабирование хранилищ "на лету"
• Отказоустойчивая конфигурация из двух или трех узлов кластера хранилищ
• Использование существующих серверов и хранилищ данных
• Простое администрирование решения
• Встроенные механизмы дедупликации и резервного копирования виртуальных машин

Тем, кого заинтересовала программа IaaS у компании StarWind, необходимо обратиться по адресу sales@starwindsoftware.com.

На сайте Фрэнка Деннемана появилась отличная статья про механизмы "горячей" миграции хранилищ (Storage vMotion) и "горячей" миграции виртуальных машин (vMotion) в контексте их использования для одного хранилища (Datastore) или хоста ESXi в VMware vSphere. Мы просто не можем не перевести ее, так как она представляет большой интерес для понимания работы этих механизмов.

Начнем со Storage vMotion. Данная операция, очевидно, требует большой нагрузки как на хранилище, откуда и куда, переносятся виртуальные машины, так и на сам хост-сервер VMware ESXi. Особенно актуально это, когда хост или хранилище переходят в Maintenance Mode, и виртуальные машины массово начинают миграцию. В случае со Storage vMotion это создает колоссальную нагрузку на хранилище по вводу-выводу.

Для понимания затрат ресурсов на эти процессы Фрэнк вводит понятие "цены" (cost) начинающейся операции, которая не может превосходить количество доступных слотов на хосте или хранилище, выделенных под них. Наглядно это можно представить так:

Resource Max Cost - это максимальный объем в неких единицах (назовем их слотами), который находится в рамках пула доступных ресурсов для операции Storage vMotion. Для хоста ESXi емкость такого пула составляет 8 слотов, а цена операции Storage vMotion - 4 слота. Таким образом, на одном хосте ESXi могут одновременно выполняться не более 2-х операций Storage vMotion. Если выполняется одна операция - то занято 4 слота и 4 слота свободно (как для исходного, так и для целевого хранилища).

С хранилищем точно такая же система - но у него 128 слотов. Одна операция Storage vMotion для Datastore потребляет 16 слотов. Таким образом, на одном хранилище может выполняться 8 (128 / 16) одновременных операций Storage vMotion. Их могут инициировать, например, 4 хоста (по 2 операции максимально каждый). То есть, мы получаем следующую схему:

Все просто и понятно. Отметим здесь, что операция vMotion тоже потребляет ресурсы с Datastore - но всего 1 слот. Таким образом, на одном Datastore могут, например, выполняться 7 одновременных миграций Storage vMotion (7 * 16 = 112 слотов) и еще 16 миграций vMotion (112+16 = 128), задействующих ВМ этого Datastore.

Если вы не хотите, чтобы при переводе Datastore в Maintenance Mode на нем возникало сразу 8 одновременных миграций Storage vMotion и, как следствие, большой нагрузки, вы можете уменьшить пул слотов для хранилищ (для всех, а не для какого-то конкретно). Для этого нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:

%ALLUSERPROFILE%\Application Data\VMware\VMware VirtualCenter\

Там нужно вписать новое значение в следующую секцию, где "new value":

< config >
< vpxd >
< ResourceManager >
< MaxCostPerEsx41DS > new value < /MaxCostPerEsx41DS >
< /ResourceManager >
< /vpxd >
< /config >

Вбив значение 112, вы уменьшите максимальное число одновременных миграций Storage vMotion на Datastore до 7. На хосте ESXi менять размер пула слотов для Storage vMotion не рекомендуется (хотя такие секции можно добавить - это пробовали энтузиасты).

Про стоимость миграций vMotion для хостов ESX / ESXi 4.1 мы уже писали вот тут. На эту тему есть также статья KB 2001417. С тех пор в vMotion много чего изменилось, поэтому подтвердить актуальность для vSphere 5 пока не могу. Буду признателен, если вы напишете об этом в комментариях.

Новость эта не свежая, однако стоит упоминания на нашем сайте. 7 июня этого года компания Microsoft объявила о том, что облачный сервис Microsoft Windows Azure является теперь не только PaaS-решением (Platform-as-a-Service), но и IaaS-продуктом (Infrastructure-as-a-Service), что выводит Microsoft на один рынок с Amazon AWS. Очевидно, что в Microsoft поняли, что PaaS - это еще слишком немассовая концепция для пользователей, а IaaS сейчас набирает популярность и имеет больший приоритет. Теперь из облака Windows Azure можно брать вычислительные мощности виртуальных машин в аренду, как на базе Windows (2008 и 2012), так и на базе Linux-платформ (в галерее образов есть OpenSUSE, CentOS, Ubuntu и SUSE Linux Enterprise Server).

Важным моментом является то, что виртуальные машины Windows Azure, работающие на виртуальных дисках VHD, можно перемещать между локальным облаком предприятия и облаком Azure, а значит можно строить гибридные облака, объединяющие инфраструктуру предприятия и публичное облако Azure. К арендованным виртуальным машинам можно прикрутить PaaS-сервисы, такие как Microsoft SQL Server, а также SaaS-приложения, доступные на Windows Azure Marketplace.

Windows Azure состоит из:

• Compute — компонент, реализующий вычисления на платформе Windows Azure, предоставляет среду выполнения на основе ролевой модели.
• Storage — компонент хранилища предоставляет масштабируемое хранилище. Компонент хранилища не имеет возможности использовать реляционную модель и является альтернативой (либо дополняющим решением) SQL Databases (SQL Azure) — масштабируемой «облачной» версией SQL Server.
• Fabric — Windows Azure Fabric по своему назначению является «контролёром» и ядром платформы, выполняя функции мониторинга в реальном времени, обеспечения отказоустойчивости, выделении мощностей, развертывания серверов, виртуальных машин и приложений, балансировки нагрузки и управления оборудованием.

Платформа Windows Azure имеет API, построенное на REST, HTTP, и XML, что позволяет разработчикам использовать «облачные» сервисы с любой операционной системы, устройства и платформы.

Аптайм виртуальных машин гарантируется на уровне 99.9% согласно SLA.

Бесплатный доступ к Windows Azure в течение 30 дней можно получить без кредитной карты и прочих платежных данных на сайте официального дистрибьютора сервисов Azure, а если вы хотите триал на 90 дней, то понадобится указать данные кредитной карты, которая оформлена в США, и будьте готовы заплатить за превышение указанных в условиях лимитов использования вычислительных ресурсов.

• Среда выполнения: 3 small compute instances (см. таблицу ниже)
• Хранение: 3GB of storage
• SQL Azure Two 1GB Web Edition database
• AppFabric: 100,000 Access Control transactions, 2 Service Bus connections
• Data Transfers (per region): 3 GB in/3 GB out

Ценообразование также указано на сайте, посвященном Windows Azure:

Клиенты при использовании предварительной версии для средних и крупных вычислительных операций могут также развертывать виртуальную машину с пробной версией Windows с SQL Server 2012 из коллекции образов. Чтобы использовать возможности SQL Server 2012 Enterprise, пробная версия SQL Server 2012 должна быть развернута на крупной или очень крупной виртуальной машине Windows Azure.

До полной доступности Windows Azure цены пока ниже на 33%.

Виртуальная машина Windows включает стоимость лицензий на Windows Server. Виртуальная машина не под управлением Windows позволяет отдельно лицензировать и развертывать операционную систему сервера виртуальных машин (не Windows).

Потребленные часы оплачиваются при развертывании виртуальных машин всегда, независимо от того, запускались они или нет. Потребленные часы не включают затраты на хранилище Windows Azure, связанные с выполнением образа в виртуальных машинах Windows Azure. По этим затратам выставляется отдельный счет.

Кроме этого, в начале июня компанией Microsoft были анонсированы также следующие новые возможности в Windows Azure:

• Windows Azure Virtual Network — возможность управления виртуальными частными сетями (VPN) в облаке Windows Azure, а также растягивание внутренних сетей предприятия на облако Azure. 
• Windows Azure Web Sites — возможность разработки и хостинга веб-сайтов с поддержкой .NET, Node.js, and PHP. 
• New tools, language support, and SDK — новый Windows Azure SDK от июня 2012 включает в себя новые инструменты по разработке кода на Java, PHP, .NET и Python.
• Windows Azure Management Portal - возможность централизованного управления сервисами Azure, включающими Cloud Services, Virtual Machines, Web Sites, Virtual Network, SQL Database (ранее SQL Azure) и хранилищем.
• Availability in New Countries — доступность сервисов в 89 странах, включая Россию и включая расчеты в рублях.

Большое количество обзорных видео, касающихся Windows Azure доступно на выделенном канале YouTube: http://www.youtube.com/user/windowsazure. Для начала также рекомендуем почитать документ Fact Sheet.

Ведущие вендоры решений для виртуализации настольных ПК предприятия (а их всего два - Citrix и VMware) постоянно ищут пути оптимизации своих продуктов для получения максимальной производительности виртуальных ПК во всех аспектах: вычислительные ресурсы, сети и хранилища. Это неудивительно, так как, зачастую, именно по этому показателю пользователи выбирают подходящее им решения. Мы уже много писали о технологии VMware Storage Accelerator, которая есть в решении VMware View 5.1 - она использует оперативную память хост-серверов ESXi для кэширования блоков виртуальных машин.

Но надо помнить, что еще раньше компания Citrix тоже разработала технологию оптимизации хранилищ виртуальных ПК - IntelliCache для продуктов Citrix XenServer и XenDesktop, которая, правда, работает несколько по-иному: блоки данных виртуальных машин кэшируются не в оперативной памяти, а на локальном хранилище сервера XenServer.

Технология Citrix IntelliCache кэширует блоки данных виртуальных ПК на локальном диске (само собой, лучше использовать SSD-накопители) при записи данных на общее хранилище, а когда они запрашиваются с последнего виртуальными машинами, то просматривается локальный кэш и отдаются кэшированные блоки виртуальной машины напрямую с локального хранилища. Соответственно, если используется высокопроизводительное локальное хранилище - блоки виртуальным машинам будут отдаваться существенно быстрее, что позволит, например, сгладить последствия событий Boot Storm или Antivirus Storm. При выключении или перезагрузке виртуальной машины - локальный кэш очищается.

Для каждой виртуальной машины могут быть созданы 2 типа файлов на локальном хранилище в целях обеспечения работы IntelliCache - несколько файлов write cache и один файл shared read cache (файлы типа <uuid>.vhdcache на локальном репозитории). Здесь надо отметить, что при работе Citrix XenDesktop есть 2 режима работы виртуальных ПК с кэшем IntelliCache:

• Shared Desktop Mode - когда опция on-boot выставлена в значение reset, а флаг allow-caching - в значение true. В этом случае отличия виртуального ПК от базового образа (дельта) будет писаться только на локальный диск, минуя общее хранилище. Это позволит использовать комбинацию чтения с общего хранилища (базовый образ) и чтения/записки на локальном хранилище сервера XenServer, что увеличивает производительность как чтения, так и записи данных. Однако, разумеется, для таких виртуальных машин нельзя использовать такие технологии как XenMotion и High Availablity, так как часть данных ВМ хранится только локально. Это лучше использовать для неперсистентных десктопов и дисков, состояние которых не сохраняется при выключении или перезагрузке (pooled desktops).
• Private Desktop Mode - когда опция on-boot выставлена в значение persist, а флаг allow-caching - в значение true. В этом случае данные пишутся одновременно в кэш и на общее хранилище, а кэш позволяет оптимизировать производительность только при чтении данных. При этом для виртуальной машины работают все технологии, требующие общего хранилища. Такую технику лучше использовать, когда используются постоянные виртуальные ПК с сохранением данных при выключении (dedicated desktops).

Технология IntelliCache дает существенный выигрыш в производительности в инфраструктуре VDI (тесты Login VSI):

Для использования IntelliCache при установке XenServer потребуется создать локальный storage repository (SR) с поддержкой данной технологии, которая, напомним, появилась в Citrix XenServer 5.6 SP1 (поэтому для более ранних версий продукта эта технология работать не будет). При установке нужно не забыть отметить галку "Enable thin provisioning (Optimized storage for XenDesktop)".

Со стороны инфраструктуры XenDesktop вам понадобится XenDesktop 5 service pack 1 или более поздней версии, где поддержка технологии IntelliCache включается одной галкой в мастере добавления хост-сервера:

Так как локальные репозитории предшествующих версий XenServer построены на базе LVM, а SR с поддержкой IntelliCache используют EXT3, конвертировать старые локальные репозитории в новые получится только с полной потерей данных на репозитории. Чтобы сделать это, нужно выполнить следующую последовательность команд:

localsr='xe sr-list type=lvm host=<hostname> params=uuid --minimal'
echo localsr=$localsr
pbd='xe pbd-list sr-uuid=$localsr params=uuid --minimal'
echo pbd=$pbd
xe pbd-unplug uuid=$pbd
xe pbd-destroy uuid=$pbd
xe sr-forget uuid=$localsr
sed -i "s/'lvm'/'ext'/" /etc/firstboot.d/data/default-storage.conf
rm -f /etc/firstboot.d/state/10-prepare-storage
rm -f /etc/firstboot.d/state/15-set-default-storage
service firstboot start
xe sr-list type=ext

Далее на созданном репозитории включаем поддержку кэширования IntelliCache:

xe host-disable host=<hostname>
localsr='xe sr-list type=ext host=<hostname> params=uuid --minimal'
xe host-enable-local-storage-caching host=<hostname> sr-uuid=$localsr
xe host-enable host=<hostname>

Более подробную информацию о Citrix IntelliCache можно получить из следующих источников:

• XenServer 5.6 SP2 and XenDesktop 5 SP1 now fully support IntelliCache
• Digging in to Citrix XenServer 5.6 FP's new “IntelliCache” feature. Hint: It’s a BIG deal for desktops!
• How to Use IntelliCache with XenDesktop
• XenServer 5.6 Service Pack 2 Installation Guide
• XenDesktop 5 with IntelliCache cuts VDI storage costs in half
• XenDesktop and local storage + IntelliCache

В первой части статьи о продукте vGate R2, предназначенном для защиты виртуальной инфраструктуры VMware vSphere, мы рассмотрели механизмы того, как с помощью него можно защитить инфраструктуру сервис-провайдера от внешних уроз в сфере информационной безопасности. В этой части статьи мы рассмотрим не менее важный аспект защиты инфраструктуры виртуализации - защиту от внутренних (инсайдерских) угроз в датацентрах средствами сертифицированного ФСТЭК решения vGate R2.

Как мы уже писали в одной из статей, в VMware vSphere 5 при работе виртуальных машин с хранилищами могут возникать 2 похожих по признакам ситуации:

APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация. Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.

В логе /var/log/vmkernel.log ситуация APD выглядит подобным образом:

2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_IssueCommandToDevice:2954:I/O could not be issued to device "naa.60a98000572d54724a34642d71325763" due to Not found
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...

Ключевые слова здесь: retry, awaiting. Когда вы перезапустите management agents, то получите такую вот ошибку:

Not all VMFS volumes were updated; the error encountered was 'No connection'.
Errors:
Rescan complete, however some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds still using these paths.
Error while scanning interfaces, unable to continue. Error was Not all VMFS volumes were updated; the error encountered was 'No connection'.

В этом случае надо искать проблему в фабрике SAN или на массиве.

PDL (Permanent Device Loss) - когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет (понятно, что в случае APD по причине свича мы такого ответа не получим). Этот статус считается постоянным, так как массив ответил, что устройства больше нет.

А вообще есть вот такая табличка для SCSI sense codes, которые вызывают PDL:

В случае статуса PDL гипервизор в ответ на запрос I/O от виртуальной машины выдает ответ VMK_PERM_DEV_LOSS и не блокирует демон hostd, что, соответственно, не влияет на производительность. Отметим, что как в случае APD, так и в случае PDL, виртуальная машина не знает, что там произошло с хранилищем, и продолжает пытаться выполнять команды ввода-вывода.

Такое разделение статусов в vSphere 5 позволило решить множество проблем, например, в случае PDL хост-серверу больше не нужно постоянно пытаться восстановить пути, а пользователь может удалить сломавшееся устройство с помощью операций detach и unmount в интерфейсе vSphere Client (в случае так называемого "Unplanned PDL"):

В логе /var/log/vmkernel.log ситуация PDL (в случае Unplanned PDL) выглядит подобным образом:

2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba3:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba4:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: vmw_psp_rr: psp_rrSelectPathToActivate:972:Could not select path for device "naa.60a98000572d54724a34642d71325763".
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: ScsiDevice: 1223: Device :naa.60a98000572d54724a34642d71325763 has been removed or is permanently inaccessible.
2011-08-09T10:43:26.857Z cpu3:2132)ScsiDeviceIO: 2288: Cmd(0x4124403c1fc0) 0x9e, CmdSN 0xec86 to dev "naa.60a98000572d54724a34642d71325763" failed H:0x8 D:0x0 P:0x0
2011-08-09T10:43:26.858Z cpu3:2132)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-08-09T10:43:26.858Z cpu2:2127)ScsiDeviceIO: 2316: Cmd(0x4124403c1fc0) 0x25, CmdSN 0xecab to dev "naa.60a98000572d54724a34642d71325763" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.858Z cpu2:854568)WARNING: ScsiDeviceIO: 7330: READ CAPACITY on device "naa.60a98000572d54724a34642d71325763" from Plugin "NMP" failed. I/O error
2011-08-09T10:43:26.858Z cpu2:854568)ScsiDevice: 1238: Permanently inaccessible device :naa.60a98000572d54724a34642d71325763 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.
2011-08-09T10:43:26.859Z cpu3:854577)WARNING: NMP: nmpDeviceAttemptFailover:562:Retry world restore device "naa.60a98000572d54724a34642d71325763" - no more commands to retry

Ключевое слово здесь - permanently.

Становится понятно, что в случае, когда устройство хранения (LUN) реально сломалось или удалено сознательно, лучше всего избежать ситуации APD и попасть в статус PDL. Сделать это удается хост-серверу ESXi не всегда - по прежнему в vSphere 5.0 Update 1 это обрабатывается в ограниченном количестве случаев, но в vSphere 5.1 обещают существенно доработать этот механизм.

Также есть Advanced Settings на хосте ESXi, которые позволяют управлять дальнейшей судьбой машины, которая оказалась жертвой ситуации PDL. В частности есть 2 следующие расширенные настройки (начиная с vSphere 5.0 Update 1) - первая в категории "Disk", а вторая в расширенных настройках кластера HA:

disk.terminateVMonPDLDefault - если эта настройка включена (True), то в ситуации PDL для устройства, где находится ВМ, эта машина будет выключена. Настройка задается на уровне хоста ESXi и требует его перезагрузки для ее применения.

das.maskCleanShutdownEnabled - это настройка, будучи включенной (True), позволяет механизму VMware HA приступить к восстановлению виртуальной машины. Соответственно, если она выключена, то HA проигнорирует выключение виртуальной машины в случае ее "убийства" при включенной первой настройке.

Рекомендуется, чтобы обе эти настройки были включены.

Все описанные выше механизмы могут очень пригодиться при построении и обработке сбоев в "растянутых кластерах" VMware HA, построенных между географически разнесенными датацентрами. Об этом всем детально написано в документе "VMware vSphere Metro Storage Cluster Case Study".

Компания StarWind, выпускающая продукт номер 1 для создания отказоустойчивых iSCSI-хранилищ серверов VMware vSphere и Microsoft Hyper-V, опять объявила о бесплатной раздаче NFS-лицензий на StarWind iSCSI SAN и StarWind Native SAN for Hyper-V для определенных групп ИТ-профессионалов. В их число входят:

• VMware vExpert
• VMware Certified Instructor (VCI)
• Microsoft Most Valuable Professional (MVP)
• Microsoft Certified Trainer (MCT)
• Citrix Technology Professional (CTP)
• Citrix Certified Instructor (CCI)

Тут вы можете прочитать о возможностях новой версии StarWind iSCSI SAN 5.9. А получить бесплатные NFR-лицензии можно по этой ссылке: http://www.go.starwindsoftware.com/free-nfr-license, либо написав письмо по адресу: roman.shovkun@starwindsoftware.com. Сделать это можно до 30 сентября 2012 года.

Традиционно, бесплатные лицензии раздаются только для непроизводственного использования, т.е. только для целей тестирования, обучения, демонстраций и т.п. Ну и напомним, что если вы не принадлежите к данным группам ИТ-профессионалов, вы всегда можете скачать бесплатную версию StarWind iSCSI SAN Free, где есть следующие возможности:

• Дедупликация блоков виртуальных дисков
• Техники защиты данных: CDP и снапшоты
• Thin Provisioning (диски, растущие по мере наполнения их данными)
• Высокопроизводительное кэширование

Мы уже писали о новых возможностях VMware View 5.1 и, в частности, о технологии Storage Accelerator, которая использует кэш CBRC на чтение на стороне хоста VMware ESXi, чтобы быстрее отдавать блоки виртуальной машине напрямую из памяти, не обращаясь к хранилищу.

Как понятно из названия (Content Based Read Cache), технология Storage Accelerator позволяет оптимизировать ввод-вывод именно тогда, когда в среде виртуальных ПК у нас много операций чтения, которые происходят для множества связанных клонов, развертываемых из реплики View Compser. Таких показательных ситуаций две: Boot Storm (когда пользователи приходят на работу и одновременно включают свои ПК для доступа к своим виртуальным машинам) и Antivirus Storm (когда антивирус начинает шерстить файлы в гостевой ОС).

Интересные картинки по тестированию данной технологии обнаружились в одном из тестов Login VSI, которая проверила, как это работает на хосте со 143-мя связанными клонами виртуальных ПК для размера кэша CBRC размером в 2 ГБ. Работает это замечательно:

Как мы видим, к сотой минуте нагрузка улеглась и операции чтения стали уже не такими однородными. Для постоянных (persistent) дисков (т.е. тех, которые не развертываются из единого базового образа) технология CBRC тоже дает свои плоды:

Ну и здорово помогает нам View Storage Accelerator при антивирусном шторме, когда антивирусники большого количества виртуальных машин одновременно набрасываются на файлы гостевых ОС:

Ну и под конец напомним, что в качестве антивирусных решений в VDI-средах для оптимизации нагрузки нужно использовать решения с поддержкой VMsafe.

Мы уже писали об облачной платформе  Amazon Web Services (AWS), куда включен продукт Amazon Elastic Compute Cloud (EC2) - один из самых известных сервисов IaaS по аренде ресурсов для виртуальных машин. Недавно компания Amazon объявила, что теперь есть не только возможность импорта виртуальных машин на платформах вендоров VMware, Citrix и Microsoft, но и обратный их экспорт в частное облако клиента в соответствующих форматах. Несмотря на то, что технически сделать это весьма просто, компания затягивала с этой возможностью.

Напомним, что импорт виртуальной машины, например с VMware vSphere, можно сделать средствами Amazon EC2 VM Import Connector for VMware vCenter, который является плагином к vSphere Client:

Экспорт инстанса делается средствами командной строки с помощью задачи ec2-create-instance-export-task. Например, в формат VMware можно экспортировать следующим образом:

ec2-create-instance-export-task –e vmware -b NAME-OF-S3-BUCKET INSTANCE-ID

Для экспорта потребуется ID инстанса, имя хранилища (S3 Bucket) и тип выходного образа (vmware, citrix или microsoft).

Мониторинг процесса экспорта выполняется командой ec2-describe-export-tasks, а отмена экспорта - ec2-cancel-export-task. Полный синтаксис операций экспорта экземпляров EC2 в виртуальные машины частного облака можно изучить по этой ссылке.

Мы уже писали о некоторых особенностях дедупликации StarWind Global Deduplication, которая, кстати, предоставляется бесплатно всем пользователям решения для резервного копирования Veeam Backup and Replication. Сегодня мы раскроем еще некоторые моменты.

Какие требования предъявляет дедупликация StarWind к аппаратному обеспечению:

Процессор. Минимально на сервере StarWind вам потребуются процессоры Intel Xeon Processor E5620 (или более поздние), либо их аналог по производительности от AMD. Рекомендуются процессоры Intel Xeon X5650 для получения максимальной производительности. При этом лучше иметь больше ядер с меньшей частотой, чем меньше ядер с большей частотой (раки по 3 рубля выгоднее) - это дает большую производительность для StarWind.

Память. Минимальное требование к опреативной памяти сервера StarWind iSCSI SAN - 4 ГБ. При этом нужно учитывать, что нужно закладывать сверх этого память на 2 вещи: дедупликацию и кэширование. Размер памяти, выделяемой для кэширования, выставляется в настройках при создании устройства StarWind, а вот размер памяти, необходимый для дедупликации понятен из следующей таблицы:

Больший размер блока дедупликации дает экономию памяти и процессорных ресурсов, но ухудшает показатели эффективности дедупликации, а на малых размерах блока дедупликации вам понадобятся существенные ресурсы сервера хранилищ StarWind. Ну и от размера блока зависит максимально поддерживаемый объем дедуплицированного диска (от 2 ТБ для 512 байт до 1024 ТБ для 256 КБ).

С точки зрения программного обеспечения, StarWind iSCSI SAN поддерживает любую серверную ОС Microsoft от Windows Server 2003 до Windows 2008 R2, но последняя является рекомендуемой платформой.

В интерфейсе StarWind дедуплицированное устройство создается с помощью мастера:

Далее просто выбираем размер блока дедупликации:

При настройке задачи резервного копирования в Veeam Backup and Replication на дедуплицированное хранилище StarWind не забудьте отключить встроенную дедупликацию от Veeam и компрессию, в соответствии с рекомендациями вендоров:

Кстати, вот один из тестов, показывающих эффективность дедупликации от StarWind для бэкапов Veeam (слева - архив с резервной копией, справа - файл дедуплицированного устройства StarWind):

Также об установке StarWind и создании дедуплицированных устройств можно прочитать в документе "Configuring Global Deduplication" и "Global Deduplication with Veeam Backup&Replication".

Мы уже недавно писали о метриках производительности хранилищ в среде VMware vSphere, которые можно получить с помощью команды esxtop. Сегодня мы продолжим развивать эту тему и поговорим об общей производительности дисковых устройств и сайзинге нагрузок виртуальных машин по хранилищам в виртуальной среде.

Как говорит нам вторая статья блога VMware о хранилищах, есть несколько причин, по которым может падать производительность подсистемы ввода-вывода виртуальных машин:

• Неправильный сайзинг хранилищ для задач ВМ, вследствие чего хранилища не выдерживают такого количества операций, и все начинает тормозить. Это самый частый случай.
• Перегрузка очереди ввода-вывода со стороны хост-сервера.
• Достижение предела полосы пропускания между хостом и хранилищем.
• Высокая загрузка CPU хост-сервера.
• Проблемы с драйверами хранилищ на уровне гостевой ОС.
• Некорректно настроенные приложения.

Из всего этого набора причин самой актуальной оказывается, как правило, первая. Это происходит вследствие того, что администраторы очень часто делают сайзинг хранилищ для задач в ВМ, учитывая их требования только к занимаемому пространству, но не учитывая реальных требований систем к вводу выводу. Это верно в Enterprise-среде, когда у вас есть хранилища вроде HDS VSP с практически "несъедаемой" производительностью, но неверно для Low и Midrange массивов в небольших организациях.

Поэтому профилирование нагрузки по хранилищам - одна из основных задач администраторов VMware vSphere. Здесь VMware предлагает описывать модель нагрузки прикладной системы следующими параметрами:

• Размер запроса ввода-вывода (I/O Size)
• Процент обращений на чтение (Read)
• Процент случайных обращений (Random)

Таким образом профиль приложения для "типичной" нагрузки может выглядеть наподобие:

8KB I/O size, 80% Random, 80% Read

Само собой, для каждого приложения типа Exchange или СУБД может быть свой профиль нагрузки, отличающийся от типичного. Размер запроса ввода-вывода (I/O Size) также зависит от специфики приложения, и о том, как регулировать его максимальное значение на уровне гипервизора ESXi, рассказано в KB 1008205. Нужно просто в Advanced Settings выставить значение Disk.DiskMaxIOSize (значение в килобайтах). Некоторые массивы испытывают проблемы с производительностью, когда размер запроса ввода-вывода очень велик, поэтому здесь нужно обратиться к документации производителя массива. Если с помощью указанной настройки ограничить размер запроса ввода-вывода, то они будут разбиваться на маленькие подзапросы, что может привести к увеличению производительности подсистемы ввода-вывода на некоторых системах хранения. По умолчанию установлено максимальное значение в 32 МБ, что является достаточно большим (некоторые массивы начинают испытывать проблемы при запросах более 128 KB, 256 KB или 512KB, в зависимости от модели и конфигурации).

Однако вернемся к профилированию нагрузок по хранилищам в VMware vSphere. В одной из презентаций VMware есть замечательная картинка, отражающая численные характеристики производительности дисковых устройств в пересчете на шпиндель в зависимости от типа их организации в RAID-массивы:

Параметры в верхней части приведены для операций 100%-й последовательной записи для дисков на 15К оборотов. А в нижней части приведены параметры производительности для описанной выше "типичной" нагрузки, включая среднюю скорость чтения-записи, число операций ввода-вывода в секунду (IOPS) и среднюю задержку. Хорошая напоминалка, между прочим.

Теперь как анализировать нагрузку по вводу выводу. Для этого у VMware на сайте проекта VMware Labs есть специальная утилита I/O Analyzer, про которую мы уже писали вот тут. Она может многое из того, что потребуется для профилирования нагрузок по хранилищам.

Ну а дальше стандартные процедуры - балансировка нагрузки по путям, сторадж-процессорам (SP) и дисковым устройствам. Сигналом к изысканиям должен послужить счетчик Device Latency (DAVG) в esxtop, если его значение превышает 20-30 мс для виртуальной машины.

На днях в блогах Microsoft было объявлено о выходе предрелизной версии новой опреационной системы Windows Server 2012 Release Candidate (RC). В прошлых записях мы уже писали о вышедшей 3 месяца назад бета-версии Windows Server 2012, а также о новых возможностях Hyper-V 3.0 (и тут), которые появились в обновленной версии серверной ОС.

Кроме того, на сайте Microsoft появился отличный документ "Features Comparison: Windows Server 2008 R2 Hyper-V and Windows Server 2012 Release Candidate Hyper-V", который рассказывает об отличиях нового гипервизора Hyper-V 3.0 от его предыдущего поколения:

Этот 23-страничный документ, состоящий из таблиц, где приводится сравнение функциональности с предыдущей версией платформы виртуализации, выглядит весьма внушительно.

С момента предыдущей бета-версии существенно улучшились максимально поддерживаемые конфигурации виртуальной среды:

Также отметим, что стали доступными для загрузки обновленная версия настольной ОС Windows 8 Release Preview, а также средства управления RSAT.

Любителям священных войн мы порекомендуем документ "Competitive Advantages of Windows Server 2012 Release Candidate Hyper-V over VMware vSphere 5.0", где размещена "красная тряпка" для Воинов Света VMware vSphere:

Документ - вообще огонь. Говорят даже, что Hyper-V вам заменит VMware View и будет классным VDI-решением:

Скачать Windows Server 2012 Release Candidate (RC) можно по этой ссылке.

Компания Veeam Software, по прошествии полугода с момента выпуска шестой версии решения номер 1 для резервного копирования виртуальных машин Veeam Backup and Replication, объявила о релизе обновленной версии решения - Veeam Backup and Replication 6.1. Несмотря на то, что версия продвинулась всего лишь на 0.1, как всегда компания Veeam Software нашла чем удивить многочисленных пользователей и, в очередной раз, показала свое технологическое превосходство над конкурентами (которые еще и обделались)...
Таги: Veeam, Backup, Update, VMware, vSphere, Microsoft, Hyper-V

Счетчики esxtop в VMware vSphere 5, касающиеся хранилищ - наглядно.

Мы уже писали об основных приемах по решению проблем на хостах VMware ESX / ESXi с помощью утилиты esxtop, позволяющей отслеживать все аспекты производительности серверов и виртуальных машин. Через интерфейс RCLI можно удаленно получать эти же данные с помощью команды resxtop.

Сегодня мы приведем простое объяснение иерархии счетчиков esxtop, касающихся хранилищ серверов VMware vSphere. Для того, чтобы взглянуть на основные счетчики esxtop для хранилищ, нужно запустить утилиту и нажать кнопку <d> для перехода в режим отслеживания показателей конкретных виртуальных машин (кликабельно). Данные значения будут представлены в миллисекундах (ms):

Если мы посмотрим на колонки, которые выделены красным прямоугольником, то в виде иерархии их структуру можно представить следующим образом:

Распишем их назначение:

• GAVG (Guest Average Latency) - общая задержка при выполнении SCSI-команд от гостевой ОС до хранилища сквозь все уровни работы машины с блоками данных. Это, само собой, самое большое значение, равное KAVG+DAVG.
• KAVG (Kernel Average Latency) - это задержка, возникающая в стеке vSphere для работы с хранилищами (гипервизор, модули для работы SCSI). Это обычно небольшое значение, т.к. ESXi имеет множество оптимизаций в этих компонентах для скорейшего прохождения команд ввода-вывода сквозь них.
• QAVG (Queue Average latency) - время, проведенное SCSI-командой в очереди на уровне стека работы с хранилищами, до передачи этой команды HBA-адаптеру.
• DAVG (Device Average Latency) - задержка прохождения команд от HBA адаптера до физических блоков данных на дисковых устройствах.

В блоге VMware, где разобраны эти показатели, приведены параметры для типичной нагрузки по вводу-выводу (8k I/O size, 80% Random, 80% Read). Для такой нагрузки показатель Latency (GAVG) 20-30 миллисекунд и более может свидетельствовать о наличии проблем с производительностью подсистемы хранения на каком-то из подуровней.

Как мы уже отметили, показатель KAVG, в идеале, должен быть равен 0 или исчисляться сотыми долями миллисекунды. Если он стабильно находится в пределах 2-3 мс или больше - тут уже можно подозревать проблемы. В этом случае нужно проверить значение столбца QUED для ВМ - если оно достигло 1 (очередь использована), то, возможно, выставлена слишком маленькая величина очереди на HBA-адаптере, и необходимо ее увеличить.

Для просмотра очереди на HBA-адаптере нужно переключиться в представление HBA кнопкой <u>:

Ну и если у вас наблюдается большое значение DAVG, то дело, скорее всего, не в хосте ESX, а в SAN-фабрике или дисковом массиве, на уровне которых возникают большие задержки.

Недавно мы писали о бесплатной дедупликации StarWind для пользователей продукта Veeam Backup and Replication, которую вы можете получить вот по этой ссылке, а сегодня приведем некоторые детали этого решения.

Во-первых, StarWind Global Deduplication работает на уровне дисковых устройств (LUN), а не на уровне VMDK-дисков (как Veeam), что должно положительно сказаться на эффективности дедупликации. По оценкам некоторых пользователей, тестировавших решение, эффективность StarWind доходит до +50% по сравнению с встроенной дедупликацией Veeam.

Во-вторых, на сервере StarWind вам понадобится некоторое количество дополнительной оперативной памяти для работы механизма дедупликации. На данный момент сайзить необходимо следующим образом: 3,5 ГБ памяти на 1 ТБ дедуплицируемого хранилища. В следующих версиях StarWind этот показатель будет близок к 2 ГБ на ТБ.

В-третьих, для Veeam придется отключить компрессию для лучшего эффекта дедупликации, но поддержка этого механизма в StarWind будет добавлена в ближайших версиях. Также в следующей версии будет добавлена функция увеличения/уменьшения размеров таких устройств и дедпуликация HA-устройств. Об этом всем мы напишем дополнительно.

С 21 по 24 мая проводилась конференция EMC World 2012, где одной из главных тем были, конечно же, решения по защите данных и балансировки нагрузки между географически распределенными датацентрами. Прежде всего были анонсированы решения EMC VPLEX 5.1 и RecoverPoint 3.5:

По-прежнему, SRA-адаптера для совместного решения VMware SRM+VPLEX до сих пор нет, потому как, похоже, нет окончательной ясности, нужен ли SRM, когда есть VPLEX Metro с синхронизированными томами между датацентрами и "растянутый кластер" VMware vMSC (vSphere Metro Storage Cluster) между хостами датацентров. Безусловно, сотрудники EMC говорят, что решения взаимодополняющие (т.к. SRM - это план восстановления после сбоев, а не схема катастрофоустойчивости), но пока SRM предлагается использовать только в схеме с решением для защиты данных EMC RecoverPoint, для которого SRA-адаптер уже есть:

На эту тему появился отдельный документ "Improving VMware Disaster Recovery with EMC RecoverPoint".

Появилась также поддержка разнесенных active/active кластеров Oracle RAC в EMC VPLEX:

С точки зрения vSphere Metro Storage Cluster также появилась пара интересных новостей. Во-первых, документ "VMware vSphere Metro Storage Cluster Case Study", описываещий различные сценарии отказов в растянутом кластере высокой доступности (vMSC), построенном между двумя географически разнесенными площадками:

Также напомним про документ "Stretched Clusters and VMware vCenter Site Recovery Manager", который поможет понять, в каких ситуациях пригодится растянутый кластер, а когда без SRM не обойтись.

Во-вторых, к программе сертификации  vSphere Metro Storage Cluster program присоединилась HP Lefthand:

Более подробно об этом можно прочитать в KB 2020097 или в документе "Implementing VMware vSphere Metro Storage Cluster with HP LeftHand Multi-Site storage". В HCL компании VMware решение HP Lefthand появилось в категории "iSCSI vSphere Metro Cluster Storage".

Ну и для тех, кому интересно, о чем еще говорили на EMC World, можно почитать тут и тут.

С момента выпуска последней версии серверной платформы виртуализации Oracle VM Server 3.0 прошло уже 9 месяцев, поэтому компания Oracle, чтобы о ней, как об игроке рынка виртуализации, не забывали, выпустила обновление - Oracle VM Server 3.1.

Основные новые возможности Oracle VM Server 3.1:

• User Interface New Design - теперь многие операции выполняются в виде пошаговых мастеров.
• Drag and Drop - в веб-интерфейсе Oracle VM Manager можно перетаскивать объекты, потому что теперь используется Oracle Application
  Development Framework (ADF).
• Bulk Discovery of Oracle VM Servers - теперь по именам хостов и IP-адресам можно добавлять серверы Oracle VM.
• Hot Add vCPUs - возможность добавления виртуального процессора в работающую виртуальную машину.
• Move or Clone Virtual Machines and Templates - возможность перемещения виртуальных машин между репозиториями с сохранением параметров, а также возможность клонирования ВМ.
• Automatic Creation of Multiple Virtual Machines from a Template - возможность массового развертывания ВМ из шаблона.
• VM Console Take Over - возможность перехвата консоли ВМ другим пользователем.
• Move VM Storage Repositories - репозитории хранилищ теперь можно отвязать от одного пула серверов и привязать к другому.
• Backup/Restore Access to VM Storage Repositories - теперь репозитории экспортируются как NFS-тома, что может быть использовано софтом для резервного копирования.
• LUN Resizing - изменение размера LUN автоматически подхватывается файловой системой OCFS2 (Oracle Cluster File
  System).
• Multipath Boot from SAN - поддержка загрузки из сети хранения.
• Support for Jumbo Frames - поддержка больших кадров.
• Oracle VM Templates - новые готовые шаблоны виртуальных машин с ПО от Oracle.
• Microsoft Server Virtualization Vendor Program Validation (SVVP) - теперь продукт участвует и сертифицируется по программе.
• Updated Xen Hypervisor - используется гипервизор Xen версии 4.1.2.

Полный список нововведений в Oracle VM Server можно посмотреть вот в этом документе. Скачать Oracle VM Server 3.1 можно по этой ссылке.

Не секрет, что абсолютное большинство пользователей VMware vSphere, думающих о защите данных виртуальной среды, использует средство номер 1 для резервного копирования виртуальных машин Veeam Backup and Replication 6. Компании Veeam Software и StarWind Software недавно объявили о запуске совместной компании, в рамках которой всем пользователям Veeam Backup and Replication абсолютно бесплатно предоставляется средство дедупликации хранилищ резервных копий StarWind Global Deduplication, которое позволяет сократить требования к объему хранения до 90%.

Пример эффективности совместного использования Veeam Backup and Replication и StarWind Global Deduplication показан на картинке ниже:

Решение StarWind Global Deduplication предосталяется бесплатно всем пользователям Veeam, сертифицировано со стороны последней, а также включает в себя техническую поддержку в режиме 24/7.

Бесплатно скачать решение StarWind Global Deduplication для Veeam можно по этой ссылке: http://go.starwindsoftware.com/free-starwind-iscsi-san

Мы уже писали о новых возможностях VMware View 5.1 и новых клиентах, а сегодня поговорим о производительности этого решения для виртуализации настольных ПК предприятия. Прежде всего, напомним 2 основных документа, откуда можно узнать о том, какие техники использует VMware View и в каких моментах превосходит Citrix XenDesktop:

• VMware View 5 Performance and Best Practices - тут о самих механизмах оптимизации PCoIP
• Desktop Virtualization with VMware View 5 Compared to Citrix XenDesktop 5.5 - тут исследование (утвержденное компанией VMware) о сравнении View с Citrix XenDesktop.

Приведем также некоторые ссылки на статьи, где мы уже писали о техниках оптимизации протокола PCoIP в VMware View:

• Кэширование в VMware View: CBRC и Client Side Caching - кэширование блоков на чтение на стороне хостов ESXi, а также на стороне клиентов
• Оптимизация протокола PCoIP в VMware View 5 - 4 простых способа - как настроить PCoIP под имеющийся канал
• Конфигурация настроек протокола PCoIP для ПК VMware View 5 из графического интерфейса
• Включение и отключение Build to Loseless (BTL) в VMware View 5 при доступе через LAN/WAN
• Тест на производительность: сравнение PCoIP в VMware View 5 и View 4.6 - очень весомый скачок в производительности PCoIP в пятой версии View

Теперь VMware View 5.1 идет еще дальше по сравнению с версией 5.0:

1. Появилась функция VMware View Storage Accelerator

Этот механизм позволяет использовать оперативную память сервера для кэширования наиболее часто используемых блоков данных виртуальных ПК, запрашиваемых с конечного устройства. Делается это средствами технологии Content Based Read Cache (CBRC), поддержка которой уже имеется в VMware vSphere 5.0. Эта штука, само собой, положительно влияет на скорость обмена данными с конечными устройствами и производительность операций ввода-вывода для виртуальных ПК, поскольку блоки запрашиваются напрямую из памяти хост-сервера:

Этот тест проводился для 50 виртуальных ПК с гостевой ОС Windows 7 и были достигнуты следующие результаты (по сравнению с ситуацией, когда CBRC отключен):

• Увеличение до 80% пиковых IOPS
• Увеличение на 45% средних IOPS
• Увеличение пиковой скорости обмена с ПК до 65%
• Увеличение средней скорости обмена с ПК на 25%

2. Оптимизация клиентов VMware View 5.1

Со стороны клиентов, компания VMware внесла множество улучшений, большинство которых сделано для увеличения производительности воспроизведения видео. По сравнению с версией View 5.0, клиенты View 5.1 дают следующий прирост в плане видео:

При этом отметим, что улучшения были сделаны как для x86, так и для ARM-клиентов.

3. Улучшения коммуникации клиент-сервер в View 5.1.

В механизмах коммуникации клиента VMware View 5.1 с виртуальной машиной на сервере было сделано множество умных и полезных улучшений, сводящихся к тому, что клиент чаще и быстрее взаимодействует с виртуальным ПК, что приводит к приросту производительности операций перетаскивания объектов (и гладкости их прорисовки), а также скроллинга. Вот, например, как отличается прорисовка кривых по протоколам PCoIP (View 5.1) и RDP:

Для тех, кто интересуется тем, как именно это делается, есть специальная техническая статья "Comprehensive User Experience Monitoring" от инженеров VMware.

В общем, если и раньше были объективные причины предлагать клиентам Citrix XenDesktop по причине высокой производительности протокола Citrix HDX, то теперь их практически не осталось. С каждой новой версией видно, что VMware инвестирует в PCoIP, а XenDesktop просто стоит дороже.

Мы уже не раз писали о типах устройств в продукте StarWind iSCSI Target, который предназначен для создания отказоустойчивых iSCSI-хранилищ для серверов VMware vSphere и Microsoft Hyper-V, однако с тех времен много что изменилось: StarWind стал поддерживать дедуплицированные хранилища и новые типы устройств, которые могут пригодиться при организации различных типов хранилищ и о которых мы расскажем ниже...

Вы уже, наверняка, читали про новые возможности VMware View 5.1, а на днях обновился калькулятор VDI Flash Calculator до версии 2.8, предназначенный для расчета вычислительных мощностей и хранилищ, поддерживающий новые функции платформы виртуализации настольных ПК.

Среди новых возможностей калькулятора VDI:

• Поддержка VMware View 5.1
• Поддержка функции VMware View CBRC для системного диска (Content Based Read Cache) - предполагается уменьшение интенсивности ввода-вывода на чтение на 65%
• Поддержка связанных клонов на томах NFS для кластеров vSphere, состоящих из более чем 8-ми хостов
• Поддержка платформ с высокой плотностью размещения виртуальных ПК
• Поддержка разрешения экрана 2560×1600
• Небольшие изменения в интерфейсе

Ну и небольшое обзорное видео работы с калькулятором:

Компания Citrix Systems на проходящей в Сан-Франциско конференции Citrix Synergy 2012 сделала несколько важных заявлений, относящихся к продуктовой линейке виртуализации настольных ПК, и о других продуктах компании.

Итак, список основных новостей от Citrix:

• Продукт GoToAssist теперь доступен для Android-устройств и полностью бесплатно.
• Продукт GoToMeeting с поддержкой технологии HD Faces теперь доступен для iPad
• Поддержка тонкого клиента Wyse Xenith 2 (40% выше производительность сессий, безопасность, HD-графика, оптимизация при работе в WAN).
• Продукт VDI-in-a-Box теперь можно обновить лицензией до XenDesktop.
• Запущен проект Citrix AppDNA 6.1 (подробнее здесь).
• Компания VirtualComputer, выпускающая единственного конкурента клиентского гипервизора CItrix XenClient - продукт NxTop, приобретена компанией Citrix. Теперь нет конкурентов:)
• Продукт XenClient Enterprise Edition будет выпущен во втором квартале 2012 года и будет входить в издание XenDesktop Platinum.
• Анонсировано технологическое превью Project Aruba - расширения VDI-in-a-Box, которое позволяет упростить процедуры развертывания, администрирования и доставки виртуальных ПК средствами технологии vDisk и других. Виртуальные ПК, доставляемые таким образом, будут доступны как от сервис-провайдеров (Citrix Service Provider, CSP), так и на площадках заказчиков в частных облаках.
• Компания Podio приобретена компанией Citrix. Это платформа совместной проектной работы с поддержкой ПО для совещаний Citrix GoToMeeting (кстати, бесплатно на 5 пользователей) и сервиса хранения ShareFile от Citrix.
• Анонсирован ShareFile with StorageZones - возможность контроля хранения данных в зависимости от их типа в частном или публичном облаке. Сам сервис ShareFile может быть развернут как внутри инфраструктуры компании, так и в публичном облаке сервис-провайдера. Поддерживается он из клиента Citrix Receiver и по функциям напоминает Dropbox, а также Project Octopus от VMware.
• Также клиент Citrix Receiver с поддержкой возможности Follow-Me Data будет доступен в июле этого года.
• Анонсированы новые функции Cloud Gateway 2 - средства федерации SaaS-приложений и облаков Citrix в едином фронтенде (см. VMware Horizon). Новые возможности включают в себя средства доступа через Receiver к интрасети без браузера, унифицированный безопасный фронтенд для корпоративных Web, SaaS и Windows-приложений, а также средство iJacket, предоставляющее контейнеры для устройств с различными форм-факторами.
• Компонент CloudBridge (бэкенд Cloud Gateway для соединения со своим датацентром или облачным провайдером) будет доступен в июне этого года.
• Технология XenDesktop Flexcast теперь поддерживает функцию Remote PC.
• Представлены новые улучшения протокола HDX для CAD-приложений.
• Представлена платформа Citrix CloudPlatform, основанная на продукте Apache CloudStack, которая доступна уже сегодня.
• Представлен Project Avalon = CloudStack + XenApp/XenDesktop + оркестрация сервисов в "облачном стиле". О том, что это такое, можно прочитать вот тут.

Теперь несколько скриншотов. Citrix ShareFile, как и DropBox, монтирует папку из облака в Windows:

Концепция Follow-Me Data:

Архитектура Project Avalon:

В общем, компания Citrix все больше фокусируется на облаках и доставке сервисов пользователю, но все дальше уходит от серверной виртуализации, которая, по-сути, осталась уже в прошлом.

Как известно, многие консольные команды старой сервисной консоли VMware ESX (например, esxcfg-*) в ESXi 5.0 были заменены командами утилиты esxcli, с помощью которой можно контролировать весьма широкий спектр настроек, не все из которых дублируются графическим интерфейсом vSphere Client. В списке ниже приведены некоторые полезные команды esxcli в ESXi 5.0, которыми можно воспользоваться в локальной консоли (DCUI) или по SSH для получения полезной информации как о самом хост-сервере, так и об окружении в целом.

1. Список nfs-монтирований на хосте:
# esxcli storage nfs list

2. Список установленных vib-пакетов:
# esxcli software vib list

3. Информация о памяти на хосте ESXi, включая объем RAM:
# esxcli hardware memory get

4. Информация о количестве процессоров на хосте ESXi:
# esxcli hardware cpu list

5. Список iSCSI-адаптеров и их имена:
# esxli iscsi adapter list

6. Список сетевых адаптеров:
# esxcli network nic list

7. Информация об IP-интерфейсах хоста:
# esxcli network ip interface list

8. Информация о настройках DNS:
# esxcli network ip dns search list
# esxcli network ip dns server list

9. Состояние активных соединений (аналог netstat):
# esxcli network ip connection list

10. Вывод ARP-таблицы:
# network neighbors list

11. Состояние фаервола ESXi и активные разрешения для портов и сервисов:
# esxcli network firewall get
# esxcli network firewall ruleset list

12. Информация о томах VMFS, подключенных к хосту:
# esxcli storage vmfs extent list

13. Мапинг VMFS-томов к устройствам:
# esxcli storage filesystem list

14. Текущая версия ESXi:
# esxcli system version get

15. Вывод информации о путях и устройствах FC:
# esxcli storage core path list
# esxcli storage core device list

16. Список плагинов NMP, загруженных в систему:
# esxcli storage core plugin list

17. Рескан HBA-адаптеров:
# esxcli storage core adapter rescan

18. Получить список ВМ с их World ID и убить их по этому ID (помогает от зависших и не отвечающих в vSphere Client ВМ):
# esxcli vm process list (получаем ID)
# esxcli vm process kill --type=[soft,hard,force] --world-id=WorldID (убиваем разными способами)

19. Узнать и изменить приветственное сообщение ESXi:
# esxcli system welcomemsg get
# esxcli system welcomemsg set

20. Поискать что-нибудь в Advanced Settings хоста:
# esxcli system settings advanced list | grep <var>

21. Текущее аппаратное время хоста:
# esxcli hardware clock get

22. Порядок загрузки с устройств:
# esxcli hardware bootdevice list

23. Список PCI-устройств:
# esxcli hardware pci list

24. Рескан iSCSI-адаптеров (выполняем две команды последовательно):
# esxcli iscsi adapter discovery rediscover -A <adapter_name>
# esxcli storage core adapter rescan [-A <adapter_name> | -all]

25. Список виртуальных коммутаторов и портгрупп:
# esxcli network vswitch standard list

Из основного вроде все. Если что-то еще используете - пиши плз в каменты. Полный список того, что можно сделать с esxcli, приведен в документе "Command-Line Management in vSphere 5.0
for Service Console Users".